home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c++ / 260 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  2.8 KB
  1. Path: cs.mu.OZ.AU!bounce-back
  2. From: John Max Skaller <maxtal@suphys.physics.su.oz.au>
  3. Newsgroups: comp.std.c++
  4. Subject: Re: Give operator. a chance
  5. Date: 04 Feb 96 03:39:32 GMT
  6. Organization: MAXTAL
  7. Approved: fjh@cs.mu.oz.au
  8. Message-ID: <311410F5.1BD1@suphys.physics.su.oz.au>
  9. References: <3102AD11.1663@et.se> <4e8g4t$aa3@hermes.synopsys.com>
  10. NNTP-Posting-Host: munta.cs.mu.oz.au
  11. X-Original-Date: Sun, 04 Feb 1996 11:50:45 +1000
  12. X-Mailer: Mozilla 2.0b6a (WinNT; I)
  13. X-Auth: PGPMoose V1.1 PGP comp.std.c++
  14.     iQBFAgUBMRQqiOEDnX0m9pzZAQF7KwGAhUNkuZzQlTcQZHD4QhRqhkcNVTXRd1Bb
  15.     /izdWP8u2TnZ9xaLBYEG+pZZ+F3r+Q5W
  16.     =Shg9
  17. Originator: fjh@munta.cs.mu.OZ.AU
  18.  
  19. Joe Buck wrote:
  20. > 
  21. > Dan Holmsand <dan@et.se> writes:
  22. > >Is operator.() banned from the standards discussion?
  23. > 
  24. > Yes, I suppose it is, but since you brought it up I'll discuss it anyway.
  25. > 
  26. > A formal proposal to add it (from Jim Adcock of Microsoft) was voted down
  27. > some time ago.  []
  28. > 
  29. > Some committee members objected that it's against the philosophy of C++ to
  30. > change the meaning of a builtin operator.[]
  31. > 
  32. > Others favored a more complex and non-orthogonal version, or, worse, first
  33. > said the proposal should be more complex and non-orthogonal and then
  34. > objected to the complexity and non-orthogonality in this modified version.
  35. > 
  36. > Others objected that if both operator. and operator-> were overloaded the
  37. > class would be just about impossible to implement, []
  38. > 
  39. > Others (those I respect the most) just said they didn't want extensions
  40. > without an extremely strong reason, didn't see a strong enough reason for
  41. > operator dot, but just wanted to get C++ standardized.  []
  42.  
  43.     For the record the _principal_ argument against 
  44. operator.() which killed the proposal was simply that it
  45. failed to actually provide smart references: an explicit
  46. dot was required.
  47.  
  48.     For pointers, operator-> is OK, because
  49. when no -> is used, you want a pointer and get
  50. a smart pointer, and when you want an lvalue,
  51. you have to use and explicit -> or * anyhow. 
  52.  
  53.     But for references, this is not so: 
  54. "f(lvalue &)" requires an lvalue argument.
  55. Operator.() (as proposed by Jim Adcock) doesn't
  56. convert the smart reference object to a refernece
  57. to its delegee in this context.
  58.  
  59.     As I understand it this fact was considered to
  60. cast enough doubt on the utility of Jim's proposal
  61. to reject it, particularly considering the potential
  62. confusion created, and the general lack of consensus
  63. on the issue.
  64.  
  65.  
  66. -- 
  67. John Max Skaller               voice: 61-2-566-2189
  68. 81 Glebe Point Rd              fax:   61-2-660-0850
  69. GLEBE NSW 2037                 web: http://www.maxtal.com.au/~skaller/
  70. AUSTRALIA                      email: skaller@maxtal.com.au
  71. ---
  72. [ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  73.   Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  74.   is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]
  75.